УЗБЕКСКОЕ АГЕНТСТВО СВЯЗИ И ИНФОРМАТИЗАЦИИ

ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

                                              Кафедра  Сети и системы передачи данных

ИЗУЧЕНИЕ ПРОЦЕССА УСТАНОВЛЕНИЯ

СОЕДИНЕНИЯ В ПРОТОКОЛЕ TCP

Методические указания к выполнению практического занятия

по дисциплине «Сети и системы передачи данных»

Ташкент   2011

СОДЕРЖАНИЕ:

Введение………………………………………… ………………. ……… 3

1. Общие сведения об Интернет

    Структурная организация сети Интернет ……………………… 4

1.2.        Протоколы сети Internet …………………………………………8

1.3.        Структура стека протоколов TCP/IP …………………………   10

1.4.        Протокол Интернета (IP-протокол )…………………………… 21

2.  ПРОЦЕСС УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ

В ПРОТОКОЛЕ  TCP

2.1. Установление логических соединений в протоколе TCP…………..31

2.2. Процесс установления TCP –соединения ……………………………42

     Контрольные вопросы ………………………………………………  ….63

Введение.

   В последние десятилетия сети и системы связи стали важнейшими компонентами информационной инфраструктуры общества, произошла интеграция средств связи и вычислительной техники, постепенно стираются границы между локальными и глобальными сетями, происходит конвергенция сетей, предназначенных для передачи разных видов информации. 

   Развитие информационно-коммуникационных технологий (ИКТ) является существенным компонентом современной цивилизации. Архитектурно открытое и децентрализованное, изобилующее информацией, недорогое и уникальное средство коммуникаций, предоставляемых пользователям посредством ИКТ, обоснованно подходит для развития открытого демократического общества, имеющее большое значение для экономического роста и человеческого развития всего мира. Для Узбекистана также немаловажным является динамическое развития ИКТ, о чем свидетельствует ряд важных постановлений и решений правительство направленных на разработку, внедрение и использование современных информационных и коммуникационных технологий, что позволит Узбекистану интегрироваться в международную инфокоммуникационную сеть. В этих условиях важно наличие квалифицированных кадров, умеющих ориентироваться в большом разнообразии техники и технологий и принимать важные стратегические решения.

Сети передачи данных составляющих основу сети Интернет, в настоящее время используются практически в любых родах деятельности: к примеру, они стали обязательными атрибутами транснациональных корпораций, поскольку для управления взаимодействием рабочих групп и выполнением сложных процессов требуется надежная оперативная связь. При проектировании сети необходимо грамотно выбрать её будущую топологию, сетевую технологию передачи данных, принять во внимание её будущие характеристики. Особенности работы протокола TCP, рассматриваемые в данном издании, позволят понять работу основного протокола сети Интернет.

1. ОБЩИЕ СВЕДЕНИЯ ОБ ИНТЕРНЕТ

1.1. Структурная организация сети Интернет.

          Слово Интернет происходит от термина interconnected networks (взаимосвязанные сети), т.е. c технической точки зрения - это глобальное сообщество малых и больших сетей. В более широком смысле – это информационное пространство, распределенное среди миллионов компьютеров во всем мире, которые постоянно обмениваются данными. Сеть Интернет –это удивительная технология, которая смогла вобрать в себя целый арсенал уникальных возможностей. Интернет одновременно является мощнейшим и наиболее независимым информационным ресурсом, надежным и оперативным средством связи, основное средство для развития информационных технологий и творческого самовыражения миллионов людей во всем мире.

Основная задача Интернета- это связь – связь круглосуточная, высоко надежная. Любые два компьютера, подключенные к Интернету, могут связаться друг с другом в любой момент времени. В дальнейшем, при использовании слова “Сеть ” в качестве синонима слова Интернет, будем понимать под сетью именно возможность связать любые два компьютера через Интернет и обеспечить их взаимодействие.  Все компьютеры, подключение к Интернету, относят к двум типам: Серверы и Клиенты. Компьютеры, которые предоставляют определенный сервис другим компьютерам называют серверами, а те, которые пользуются данным сервисом - клиентами. В большинстве случаев домашние клиентские компьютеры не имеют постоянного выхода в Интернет, а подключаются к сети по мере необходимости. Напротив, компьютеры – серверы постоянно соединены с Интернетом высоко скоростными каналами передачи данных, поэтому к ним всегда можно обратиться с запросом. Наряду с тем, что мы называем компьютеры клиентами или серверами, более корректно говорить о клиентах и серверах на уровне программного обеспечения. Взаимодействие приложения, при которых одна программа выступает как клиент, а другая как сервер называется клиент - серверной архитектурой (рис. 1). Программа – клиент формирует запрос, отправляет его по сети на определенный адрес и взаимодействует с программой сервером по заранее определенному протоколу. Разделение приложений на клиентскую и серверную части позволяет расположить эти программы на машинах, находящихся на любых расстояниях друг от друга.

Рис. 1  Клиент-серверная архитектура Интернета.

          Точно также на одном и том же компьютере могут располагаться несколько серверных программ. Клиентское приложение может быть расположено на том же компьютере что и серверное, а может быть расположено на компьютере, сколь угодно удаленном от сервера, но если они связаны по сети, то эта разница сводится только к задержке ответа по времени. Разделение программ на серверную и клиентскую часть позволяет им работать на разных компьютерах, связанных по Сети точно так же, как если бы они находились на одном и том же компьютере. Для каждого типа программ серверов существует своя программа клиент. Так, Web- клиент обращается к Web- серверу, почтовый клиент – к почтовому серверу и т.д.

             Таким образом, архитектура взаимодействия программного обеспечения в системе World Wide Web (WWW) построена по схеме "клиент-сервер". На рисунке 2 показано, как разделены функции в этой схеме. Программа-клиент выполняет функции интерфейса пользователя и обеспечивает доступ практически ко всем информационным ресурсам Internet. Фактически клиент—это интерпретатор НТМL, который в зависимости от команд (разметки) выполняет различные функции.

Рис. 2.  Структура "клиент-сервер"

           В круг этих функций входит не только размещение текста на экране, но и обмен информацией с сервером по мере анализа полученного НТМL-текста, что наиболее наглядно происходит при отображении встроенных в текст графических образов. При анализе URL-спецификации или по командам сервера, клиент запускает дополнительные внешние программы для работы с документами в форматах, отличных от HTML (например GIF, JPEG, MPEG, Postscript и т. п.)

          Другую часть программного комплекса WWW составляет сервер протокола НТТР, базы данных документов в формате НТМL, управляемые сервером, и программное обеспечение, разработанное в стандарте спецификации CGI. До самого последнего времени (до образования Netscape) реально использовалось два НТТР-сервера: сервер CERN и сервер NCSA. Но в настоящее время число базовых серверов расширилось. 

Прикладное программное обеспечение, работающее с сервером, можно разделить на программы-шлюзы и прочие. Шлюзы—это программы, обеспечивающие взаимодействие сервера с серверами других протоколов, например FTP или с распределенными на сети серверами Oralcle. Прочие программы— это программы, принимающие данные от сервера и выполняющие какие-либо действия: получение текущей даты, реализацию графических ссылок,  доступ к локальным базам данных или просто расчеты. Компоненты World Wide Web существуют практически для всех типов компьютерных платформ и свободно доступны в сети. Любой, кто имеет доступ в Internet, может создать свой WWW-сервер, или по крайней мере, посмотреть информацию с других серверов.

Формальная модель гипертекстовых систем,  применяющая гипертекстовую модель к информационным ресурсам, распределенным в сети, может быть описана следующими компонентами:  

• язык гипертекстовой разметки документов НТМL (НурегТехt Маrкuр- Lаnguage):

• универсальный способ адресации ресурсов в сети URL (Universal Resource Locator):

• протокол обмена гипертекстовой информацией НТТР (НурегТехt Тгаnsfeг Ргоtocоl). Позже команда NCSA добавила к этим трем компонентам четвертый:

• универсальный интерфейс шлюзов СGI (Соmmоn Gаtеwау Intеrfасе). 

Взаимодействие этих компонентов осуществляется на основе общей архитектуры взаимосвязи локальных, городских и глобальных вычислительных сетей, включающей  три уровня (рис.3):

 1. Локальные сети (LAN Lосаl Агеа Networks) - сети компьютеров, сосредоточенные на небольшой территории (1 ...2 км). Как правило, LАN-сеть располагается в одном или нескольких соседних зданиях и принадлежит одной организации.

2. Городские сети, сети метрополий (МАN - Меtropolitan Агеа Networks) -сети, объединяющие локальные сети в черте города. Протяженность сети -1...200 км.

 3. Глобальные сети WАN – (Wide Агеа Networks) объединяют территориально рассредоточенные сети LАN и МАN, а также удаленные компьютеры. MAN-сети охватывают практически все страны мира.

Рис. 3. Архитектура составной сети.

1.2    Протоколы сети Intrenet

Основу сети Интернет составляют ее протоколы, в совокупности стека  ТСР/IР определяющие взаимодействие между компьютерами в Internet.

ТСР/IР - это технология межсетевого взаимодействия, технология Internet. Сеть, которая использует технологию Internet, называется “Internet”.  Необходимо отметить, что сама технология IP сетей базируется на стеке протоколов ТСР/IP (Transmission Control Protocol/Internet Protocol). Этот стек разработан по инициативе Министерства обороны США и использован при построении сети ARPANet, из которой в дальнейшем была образована сеть Интернет. Большой вклад в разработку и усовершенствование стека внесли университеты США, особенно университет в Беркли, где был реализован ТСР/IР для операционной системы UNIX. Работы по усовершенствованию стека проводятся уже свыше 30 лет. На сегодня это самый популярный стек протоколов, который используют:

· в глобальной информационной сети Интернет;

· для построения корпоративных сетей, называемых Интранет;

· для построения корпоративных сетей с ограниченным доступом и повышенным уровнем защиты, называемых Экстранет;

· в большинстве операционных систем и ЛВС (Ethernet, Token Ring, FDDI и других);

· практически во всех глобальных сетевых технологиях (Х.25, ISDN, Frame Relay, АТМ).

           Стек ТСР/IР поддерживает большое количество протоколов канального уровня модели OSI, например SLIP и РРР, которые применяют для передачи данных на основе коммутируемых и выделенных линий связи. Свое название протокол ТСР/IР получил от двух коммуникационных протоколов (или протоколов связи). Это Transmission Control Protocol и Internet Protocol.   Сеть Internet часто называют ТСР/IР-сетью, так как эти два протокола, безусловно, являются важнейшими. В Internet используются практически все известные в настоящее время способы связи от простого провода (витая пара) до волоконно-оптических линий связи (ВОЛС). Для каждого типа линий связи разработан соответствующий протокол логического уровня, занимающийся управлением передачей информации по каналу. К протоколам логического уровня дня телефонных линий относятся протоколы SLIP (Serial Line Interface Protocol) и РРР (Point to Point Protocol).  Протоколы сетевого уровня отвечают за передачу данных между устройствами в разных сетях, то есть занимаются маршрутизацией пакетов в сети. К протоколам сетевого уровня принадлежат IР (Internet Protocol) и ARP (Address Resolution Protocol).  К протоколам транспортного уровня принадлежат ТСР (Transmission Control Protocol) и UDP (User Datagram Protocol). Протоколы уровня сеансов связи отвечают за установку, поддержание и уничтожение соответствующих каналов.  Протоколы представительского уровня занимаются обслуживанием прикладных программ. К программам представительского уровня принадлежат программы, запускаемые, к примеру, на Unix-сервере, для предоставления различных услуг абонентам. К таким программам относятся: telnet-сервер, FТР-сервер, Gopher-сервер, NFS-сервер, NNTP (Net News Transfer Protocol), SMTP (Simple Mail Transfer Protocol), РОР2 и РОРЗ (Post Office Protocol) и т.д. К протоколам прикладного уровня относятся сетевые услуги и программы их предоставления.

1.3. Структура стека протоколов ТСР/IP

            Архитектура протоколов Интернета четырех-уровневая. Появившуюся намного позже семиуровневую архитектуру протоколов эталонной модели ISO можно рассматривать как дальнейшее развитие ТСР/IР - декомпозицию двух уровней ТСР/IР. Действительно, отличие двух архитектур состоит в том, что три высших уровня (прикладной, представления данных, сеансовый) модели OSI в архитектуре ТСР/IР объединены в один - прикладной (рис. 4). Уровень сетевых интерфейсов ТСР/IР соответствует двум уровням OSI - канальному и сетевому. Прикладной уровень ТСР/IР поддерживает традиционные услуги:

· электронная почта и обмен новостями, которые реализуются с помощью простого протокола передачи электронной почты SMTP (Simple Mail Transfer Protocol); почтовых протоколов IMAP (Internet Massage Access Protocol), РОР (Post Office Protocol) и Х.400; сетевого протокола обмена новостями NNТР (Networks News Transfer Protocol);

· виртуальный терминал реализуется с помощью протокола Telnet;

· передача файлов проводится с помощью протоколов FТР (Fail Transfer Protocol), ТFТР (Trivial Fail Transfer Protocol) и NFS (Networks File Systems);

· справочные службы реализуются с помощью системы доменных имен DNS (Domain Name System) и Х.500;

· вспомогательные протоколы: получения собственных идентификаторов - ВООТР, времени - NТР (Network Time Protocol), диагностики - Echo и информации о системе – Finger.

        Сегодня популярны услуги пакетной IР-телефонии на базе протоколов SIP (Session Initiation Protocol), RТР (Real Time Transport Protocol), RTCP (Real Time Transport Control Protocol), рекомендаций Н.323 и др.

               Рис 4.  Структура стека протоколов TCP/IP

           Для сетевого взаимодействия большинство приложений пользуются услугами протоколов транспортного уровня ТСР и UDP. Протокол ТСР гарантирует надежную полнодуплексную передачу сегментов данных с предварительным установлением логического соединения. Протокол датаграмм пользователя UDP (User Datagram Protocol) обеспечивает передачу датаграмм без установления соединения, что не гарантирует их доставку.

          Передачу пакетов между сетями различной архитектуры обеспечивает основной протокол стека - IР. Датаграммный протокол IP не гарантирует надежной передачи пакетов, что, однако, увеличивает пропускную способность при передаче данных через множество сетей.

На сетевом уровне также используются:

 - диагностический протокол ICMP (Internet Control Message Protocol), который передает сообщения узлам сети об ошибках и сбоях в передаче;

 - протоколы разрешения проблемы адресов: ARP (Address Resolution Protocol) трансформирует IP адрес в физический адрес узла сети (МАС - адрес станции); RARP (Reverse Address Resolution Protocol) выполняет обратную функцию, т.е. с помощью МАС адреса определяет IP адрес.

          Работу сетевого уровня поддерживают ряд протоколов маршрутизации и сигнализации: RIP (Routing Internet Protocol), OSPF (Open Shortest Path First), IGRP (Interior Gateway Routing Protocol), EIGRP (Enhanced IGRP), BGP (Border Gateway Protocol), RAP (Routing Access Protocol), RSVP (Resource Reservation Protocol) и др.

         Стек протоколов ТСР/IР взаимодействует на канальном уровне с большим количеством протоколов и сетевых технологий, которые инкапсулируют пакеты IР протокола. На сегодня вопросам взаимодействия Интернета с другими сетями посвящено более 290 документов RFC.

            Чтобы выяснить, как выполняется передача данных с помощью любой технологии, необходимо рассмотреть следующее:

· как формируется и распределяется адресное пространство сети;

· логические характеристики (назначение полей пакетов) основных протоколов IР-технологии;

· основные процедурные характеристики протоколов, которые обеспечивают нормальное функционирование процесса передачи информации;

· каким образом решается вопрос определения путей передачи данных от отправителя к получателю, т. е. как маршрутизируются пакеты.

Преимущества семиуровневой архитектуры модели OSI

             Многоуровневая структура эталонной модели OSI обеспечивает определенные преимущества для производителей и разработчиков программного обеспечения, а также для тех специалистов, которые занимаются поддержкой функционирования этих программных продуктов, поиском и устранением неисправностей.

         Все преимущества модели OSI могут быть сформулированы следующим образом:

· Модель OSI позволяет четко определить функции каждого уровня.

· Модель OSI предоставляет в распоряжение производителей аппаратных и программных продуктов строго очерченную логическую основу для создания необходимых прикладных программ и разработки соответствующего оборудования.

· Модель OSI снижает уровень сложности процесса организации вычислительных сетей посредством разделения всей совокупности функций модели OSI на отдельные модули.

· Модель OSI поддерживает взаимодействие между разнотипными сетями и протоколами.

· Модель OSI упрощает процедуру поиска и устранения затрудняющих работу сети неисправностей посредством ограничения зоны их локализации.

· Модель OSI ускоряет совершенствование информационных технологий посредством поддержки узкой специализации при разработке программных продуктов и аппаратных средств.

Краткая характеристика уровней модели OSI

            Когда возникает необходимость в пересылке данных  (это может быть все что угодно, начиная от сообщения электронной почты и заканчивая запросом на чтение файла с удаленного хоста), запрос на пересылку этих данных подлежит пакетированию и переадресации. Система, являющаяся отправителем запроса на пересылку данных, должна выполнить соответствующие различным уровням эталонной модели OSI действия, а именно:

1. Применить к данному запросу процедуру адресации.

2. Установить соответствие между данным запросом и протоколами, которые должны его обслуживать.

3. Выполнить пакетирование запроса (другими словами, сформировать соответствующее сообщение, в котором данный запрос будет отправлен в пункт назначения).

4. Отправить запрос по каналу передачи данных для пересылки в пункт назначения.

          В процессе подготовки системой данных для пересылки по каналу связи передаваемое сообщение, прежде всего, обрабатывается редиректором, который присоединяет к нему соответствующий заголовок и управляющую информацию, а затем передает сформированное таким образом сообщение на следующий (нижний) уровень. Нижние уровни модели OSI (lower layers) обеспечивают поддержку выполнения служб, функционирующих на верхних уровнях (upper-layers). В состав этих служб входят транспортные службы (transport services), службы маршрутизации (routing services) и службы адресации (addressing services). Эти службы позволяют передавать сообщение между отправителем и получателем так же просто, как один пользователь сказал бы другому "Привет". Каждый уровень модели OSI присоединяет к сообщению свой заголовок и управляющую информацию таким образом, чтобы равноправный уровень на удаленном хосте мог удалить этот заголовок и управляющую информацию, предварительно определив, какой следующий верхний уровень должен получить передаваемое сообщение. Каждому уровню отведена строго определенная роль в подготовке данных, подлежащих пересылке по каналу связи с целью передачи в адрес удаленного хоста (см. рис. 5). Все действия, соответствующие функциям того или иного уровня, являются прозрачными для конечного пользователя.

        Рис. 5 На каждом уровне Модели OSI к сообщению, в котором передаются данные, присоединяется заголовок и управляющая информация, используемая для обработки полученных данных на соответствующем уровне хоста-получателя.

              В процессе передачи данных с одного уровня на следующий, по мере продвижения данных в направлении физического уровня и собственно физического носителя, каждый уровень присоединяет к сообщению свой заголовок или управляющую информацию. Каждый уровень, в свою очередь, рассматривает полученное им сообщение как сообщение, сформированное всеми верхними по отношению к нему уровнями. Процесс присоединения к сообщению нового заголовка на каждом очередном уровне аналогичен вложению одного конверта в другой (этот процесс называется инкапсуляцией, encapsulation).

            Рассмотрим действие изображенного выше механизма формирования и передачи сообщений с использованием модели OSI на конкретном примере. Прикладной уровень присоединяет к сообщению свой заголовок и управляющую информацию, необходимую для равноправного прикладного уровня удаленного хоста. Сформированное таким образом сообщение, в состав которого входит заголовок, управляющая информация прикладного уровня и собственно данные, передается на нижний уровень, а именно на уровень представления. Уровень представления считывает информацию, полученную от верхнего уровня как обычные данные и оставляет эти данные без внимания (не обрабатывает их). Уровень представления только присоединяет к полученному сообщению свой заголовок и управляющую информацию, необходимую для равноправного уровня удаленного хоста. Другими словами, каждый очередной нижний уровень (в данном случае уровень представления) игнорирует указанную в заголовке предыдущего уровня управляющую информацию и рассматривает ее как обычные данные, которые также не подлежат обработке. На каждом уровне в качестве управляющей используется только информация, полученная от равноправного уровня удаленного хоста. Каждый последующий уровень присоединяет свой заголовок и управляющую информацию и передает сформированное таким образом сообщение вниз, на следующий уровень.

Прикладной уровень

          Прикладной уровень модели OSI часто отождествляют с пользовательскими приложениями, такими как Word, Excel, Power Point и т.д. Прикладной уровень не имеет непосредственного отношения к собственно прикладным программам; он скорее представляет собой окно, которое позволяет передавать данные по сети между различными приложениями. 

Прикладной уровень делает возможным обмен данными между приложениями. На прикладном уровне приложения получают доступ к нижним уровням, т.е. этот уровень "открывает окно" в модель OSI. Следует помнить о том, что задача прикладного уровня состоит в предоставлении пользователю интерфейса между приложением и соответствующим протоколом стека ТСР/IР. В отличие от других уровней модели OSI, данный уровень не предоставляет свои службы ни одному из других уровней; на прикладном уровне можно получить доступ только к службам этого же уровня.

         В состав служб прикладного уровня входят следующие службы:

· Сетевые (Network Services) и межсетевые (Internetwork Services) службы приложений

· Файловые службы (File Services) и службы печати (Print Services)

· Электронная почта (E-mail)

· Доступ к сети Интернет и протокол передачи гипертекста HTTP (Hyper Text Transfer Protocol)

· Удаленный доступ к терминалам — служба Telnet.

· Протокол передачи файлов FTP (File Transfer Protocol)         

Уровень представления

           На уровне представления пересылаемые по сети данные преобразуются в единый для различных платформ формат. Уровень представления отвечает за функционирование следующих служб:

· Преобразование данных и их перевод из одного представления в другое (Data Conversion And Translation)

· Сжатие и восстановление данных (Compression/Decompression) 

· Кодирование (шифрование) и декодирование (дешифрирование) данных (encryption/decryption)

            В качестве примера протокола уровня представления можно привести протокол XDR (eXternal Data Representation, Протокол внешнего представления данных). Компания Sun Microsystems использует этот протокол для реализации своей сетевой файловой системы NFS, функционирующей на основе модели взаимодействия клиент/сервер. Файловая система NFS использует протокол ХDR. для обеспечения платформенной независимости при выполнении операций с файлами. В настоящее время протокол ХDR инкорпорирован в программный код.

Сеансовый уровень

            Сеансовый уровень отвечает за установление, поддержку и разрыв сетевых соединений между удаленными приложениями, а также за координацию работы сеансов связи. Каждый сеанс - это диалог между уровнями представления двух систем или более. Сеансовый уровень отвечает за передачу между системами запросов на предоставление различных служб и ответов на эти запросы. Кроме того, данный уровень управляет диалогом между двумя выполняемыми на различных хостах приложениями, а также регулирует поток информации, передаваемой во время сеанса связи между этими хостами.

            Примером протокола сеансового уровня может служить протокол NETBIOS (Network Bases Input Output System, Сетевая базовая система ввода-вывода). NETBIOS устанавливает сетевое соединение между двумя хостами, функционирующими под управлением операционной системы Windows NT или Windows 95. Используемый в программных продуктах компании Microsoft, протокол NETBIOS, будучи сугубо протоколом сеансового уровня, предоставляет в распоряжение пользователя службы именования и управления сеансами связи между двумя удаленными хостами посредством простого присваивания имен.

Транспортный уровень

              Принято считать, что транспортный уровень обеспечивает только гарантированную надежную доставку данных между двумя коммуникационными процессами или программами, выполняемыми на удаленных хостах. Однако это соответствует действительности только в случае, если поставщик сетевых услуг отдает предпочтение реализации транспортного протокола ТСР (Transmission Control Protocol, Протокол управления передачей), а не протокола UDP (User Datagram Protocol, Протокол передачи пользовательских дейтаграмм). Потому что протокол ТСР, будучи ориентированным на соединение протоколом (connection oriented), обеспечивает гарантированную доставку данных в пункт назначения. С другой стороны, протокол UDP — не ориентированный на соединение протокол (connectionless) — обеспечивает высокую скорость передачи данных.

          Транспортный уровень выполняет следующие функции:

· Управление сквозной передачей данных (end to end communication) между двумя выполняемыми на различных хостах процессами.

· Предоставление верхним уровням ориентированных на установление соединения (connection oriented) или не ориентированные на установление соединения (connectionless) служб.

· Идентификация выполняемых на хосте процессов по адресам портов приложе¬ний клиента и сервера (client and server port addresses).

· Сегментирование данных для приложений верхних уровней (segmenting data).

Сетевой уровень

             Первостепенной задачей сетевого уровня является присваивание логических адресов хосту-отправителю (source host) и хосту-получателю (destination host), а также определение оптимального маршрута для передачи данных между сетями.

         Сетевой уровень выполняет следующие функции:

· Сквозная передача данных между хостами (end-to-end communicatition)

· Логическая адресация (logical addressing)

· Доставка пакетов (packet delivery)

· Маршрутизация (routing)

           Для маршрутизации данных по самому оптимальному маршруту на сетевом уровне используются специальные устройства — маршрутизаторы (routing), которые выполняют маршрутизацию данных посредством коммутации пакетов (packet switching). Маршрутизатор принимает поток данных через один интерфейс, определяет сетевой адрес хоста-получателя и отправляет полученный трафик по этому адресу через другой интерфейс.

            Сетевой уровень обслуживают следующие протоколы:

· RARP, ARP, BOOTP и DHCP — протоколы, выполняющие разрешение адресов (address resolution) и их конфигурирование.

· ICMP - диагностический и управляющий протокол.

· RIP, IGRP, EIGRP, OSPF и BGP - протоколы маршрутизации.

Канальный уровень

               Основные обязанности канального уровня — это передача и прием кадров, а также физическая адресация. Перед началом процесса передачи данных на канальном уровне к каждому пересылаемому пакету данных присоединяется как заголовок (к началу пакета), так и заключительная часть (trailer) длиной четыре байта (в конец пакета). Таким образом, вокруг пакета данных образуется своеобразная рамка, или кадр (Frame) — отсюда и название передаваемого на канальном уровне пакета данных. Термин "кадрирование пакета" (packet Framing) обозначает процесс формирования кадра. Заключительная часть кадра присоединяется к пакету данных только на канальном уровне.

           Канальный уровень имеет следующие характеристики и выполняет следующие функции:

· Управление доступом к физическому носителю данных (controls access to the medium).

· Включение в состав пакета данных аппаратных адресов источника и назначения (source and destination hardware addresses).

· Подготовка данных к дальнейшему продвижению посредством преобразования пакетов данных в кадры (converting data packets to frames).

· Выполнение процедуры передачи и приема данных по физическому носителю (sending and receiving data over the wire).

· Вычисление алгоритма CRC или FCS.

· Объединение локальных сетей посредством мостов (bridges) и использование коммутаторов (switches) для передачи кадров в порты получателей.

Физический уровень

            Физический уровень имеет дело с нолями и единицами — другими словами, с битами, которые и входят в состав кадра. Биты кодируются при помощи электрических или световых импульсов (electrical or light pulses). Физический уровень регулирует также электрические и механические характеристики, кодирование сигналов и уровень напряжения. Словом, физический уровень оперирует некими осязаемыми объектами, т.е. физическими объектами, к которым можно прикоснуться, такими как кабели (cables) и повторители (repeaters).

         Физический уровень отвечает за реализацию следующих функциональных возможностей:

· Конфигурирование электрических и механических характеристик физической среды (electrical and mechanical characteristics).

· Кодирование сигналов (signal encoding).

· Передача собственно битов данных в виде нулей и единиц.

· Определение спецификаций физических соединителей (physical connector specifications).

1.4  Протокол Интернета (IР протокол).         

Протокол Интернета (IP, Internet Рrotocol) выполняет большую часть работы в стеке протоколов ТСР/IР. Все протоколы и приложения, входящие в состав ТСР/IР, выполняют свои функции на базе протокола IР (в оригинале  "run on top of IP") и используют его для логической адресации на сетевом уровне (logiса1  network lауеr аddressing),  а также для пересылки дейтаграмм между хостами Интернета.

           IР – это не ориентированный на установление соединения протокол, следовательно, его возможности по обеспечению надежности доставки дейтаграмм весьма ограничены. Это значит, что IР не гарантирует доставку дейтаграммы в пункт назначения, а скорее предпринимает попытку успешной доставки (Best effort delivery ), а именно — отсылает дейтаграмму адресату без дальнейших действий по обеспечению надежности доставки с надеждой на то, что она достигнет пункта назначения. Протокол IР просто формирует логические IР-адреса хостов отправителя и получателя на сетевом уровне и выполняет отправку дейтаграммы, оставляя при этом обеспечение надежности доставки в пункт назначения протоколам других уровней. Если возникает проблема с доставкой, то подключается протокол IСМР для формирования сообщений, которые отсылаются отправителю дейтаграммы, указывая на саму проблему и обстоятельно объясняя причины ее возникновения. Когда протокол IР обнаруживает ошибку в процессе доставки, он попросту отбрасывает дейтаграмму (удаляет ее из сети). Факт отбрасывания дейтаграммы протоколом IР является для IСМР основанием направить по адресу хоста-отправителя сообщение с указанием того, какая именно проблема возникла при пересылке дейтаграммы и по какой причине. Как уже было отмечено, решение вопроса обеспечения надежности доставки данных протокол IР оставляет за протоколами верхних уровней.

         Основной функцией протокола IР является логическая адресация хостов на сетевом уровне (logiса1 Network lауеr аddressing) и передача данных в форме дейтаграмм между хостами. Протокол IР выполняет также и другие, но не менее важные функции, такие как фрагментация (fragmentation) и сборка (reassembly) дейтаграмм. Необходимость в реализации этих функций IР возникает в случае, когда хост-отправитель пытается переслать дейтаграмму слишком большого размера и ее нужно разбить на более мелкие фрагменты. Поскольку IР — это не ориентированный на соединение протокол, он не требует установления соединения между хостами. Этот протокол не упорядочивает передаваемых сегментов данных, не генерирует подтверждений получения и не управляет потоком данных между хостами. Протокол IР обращается с каждой дейтаграммой как с отдельно взятым объектом; он просто присоединяет к дейтаграмме IР-адреса и отсылает ее с надеждой на то, что она достигнет пункта назначения. Протокол IР получает поток данных от UDP или ТСР. разбивает полученные данные на части, адресует и пакетирует каждую отдельную часть в форме дейтаграммы, которую можно пересылать далее по сети по адресу хоста-получателя. Маршрутизаторы (routers) и протоколы маршрутизации (routing рrotocols) определяют оптимальный путь (раth) между конечными хост-компьютерами На рис 2.2 представлен заголовок дейтаграммы IР в формате, который специфицирован документом КРС 791. Минимальная длина заголовка дейтаграммы IР (IР hеader) составляет 20 байт, если не используются дополнительные параметры (орtions). На рис.6 показано, как анализатор протоколов Sniffer (Sniffer Protocol analyzer) интерпретирует заголовок IР. Каждое поле заголовка дейтаграммы описано более подробно ниже.

                     Рис.6. Заголовок дейтаграммы IP.

      Рассмотрим более подробно заголовок IР, изображенный на рис. 6:

В первом поле (4 бита version) должна быть указана версия протокола IР; в настоящее время используется версия 4, являющаяся официальным стандартом.      Далее следует поле длины заголовка (4 бита IHL, Internet Нeader Length), в котором указана минимальная допустимая длина заголовка IР, равная 20 байтам.  Поле типа сервиса (Type of Service, ToS) заголовка IP (8 битов) может повлиять на выбор пути,, по которому маршрутизаторы пересылают дейтаграммы между двумя конечными системами. Биты, содержащиеся в поле ToS, позволяют приложениям и процессам верхних уровней запросить от маршрутизатора определенного уровня качества обслуживания информации. От типа предоставляемого протоколом IP сервиса зависит способ обработки дейтаграмм. До недавнего времени поле ToS полностью игнорировалось. Однако сейчас многие компании реализуют возможности, предоставляемые этим полем, для обеспечения более интеллектуального выбора пути пересылки дейтаграмм. Если поле типа сервиса не используется, ему присваивается значение 0. Поскольку применение поля ToS — явление редкое, "0" является наиболее вероятным значением битов этого поля.   Поле длины дейтаграммы в заголовке IP, имеющее размер 2 байта определяет суммарный размер всей дейтаграммы в байтах. В это значение включается длина заголовка IP и объем данных подлежащих передаче в рамках данной дейтаграммы. Поле идентификации. Перед началом сеанса передачи данных хост-отправитель присваивает каждой дейтограмме значение, которое указывается в поле идентификации длиной 2 байта. Это значение являются идентификатором дейтаграммы, обеспечивающим уникальность дейтаграммы, или потока дейтаграмм.

Поле флагов Бит 0 поля флагов (Flags) зарезервирован и должен иметь значение 0. Бит 1 может иметь одно из следующих значений:

• 0 = Флаг MF, Можно фрагментировать (May Fragment)

• 1 = Флаг DF, Не фрагментировать (Don't Fragment)

          Поле управляющих флагов заголовка IP, содержащее 3 бита, используется хостами и шлюзами для фрагментации пересылаемых данных. Если хост или шлюз поддерживает фрагментацию, он может разбить поток данных на более мелкие части перед пересылкой. В том случае, когда поддержка фрагментации не предусмотрена (установлен флаг DF — Don't Fragment, He фрагментировать), хост или шлюз не может фрагментировать поток. 

Когда хост-отправитель передает слишком большую дейтаграмму, размер которой превышает размер MTU (Maximum Transmission Unit, Максимальный модуль передачи) данного участка, шлюз выполняет фрагментацию дейтаграммы путем ее разделения на единицы меньшего (приемлемого для передачи по данной среде) размера. При наличии промежуточных шлюзов выполнение фрагментации дейтаграмм в процессе их пересылки нецелесообразно. Флаг DF (Don't fragment, Не фрагментировать), т.е. бит 1 со значением 1, запрещающим фрагментацию, имеет еще одно применение. Некоторые реализации используют этот флаг с целью динамического определения размера MTU для различных участков сети при передаче данных по сквозному соединению. Когда конечный хост предпринимает попытку переслать дейтаграмму, размер которой больше размера MTU следующего участка пути, промежуточные маршрутизаторы анализируют заголовок дейтаграммы IP и определяют, активизирован ли этот бит. Если бит 1 поля флагов оказывается установленным в значение 1 (установлен флаг DF), маршрутизатор не пересылает кадр. Вместо этого он отбрасывает дейтаграмму с передачей хосту-отправителю ICMP сообщения о том, что данная дейтаграмма имеет слишком большой размер, превышающий размер MTU следующего участка. Далее хост-отправитель может воспользоваться полученной информацией для того, чтобы изменить размер следующей дейтаграммы. Этот процесс продолжается до тех пор, пока хост-отправитель не определит подходящий размер передаваемой дейтаграммы. Это, в свою очередь, позволяет промежуточным маршрутизаторам легко избежать фрагментации дейтаграмм при их пересылке адресату.

Третий бит (бит 2) может иметь одно из следующих значений:

• 0 = Флаг Last, Последний фрагмент (Last Fragment)

• 1 = Флаг More, Есть еще фрагменты (More Fragments)

Флаги Last и More, устанавливаемые в поле этого бита, указывают на отсутствие или наличие других дейтаграмм в данном потоке. Если пересылается только одна дейтаграмма, устанавливается флаг Last (Последний фрагмент), а это свидетельствует о том, что данная дейтаграмма является первой, последней и, следовательно, единственной. Когда хост назначения получает дейтаграмму, он отмечает значение ее идентификатора, а также проверяет, какой флаг установлен в поле бита 2, Этот флаг показывает, является ли данная дейтаграмма последней или же есть еще дейтаграммы.. Если ожидается поступление других дейтаграмм (установлен флаг More, Есть еще фрагменты), хост-получатель сохраняет уже поступившие дейтаграммы в памяти до тех пор, пока не поступят другие дейтаграммы, имеющие аналогичный идентификатор. Далее хост собирает из полученных дейтаграмм поток, расположив их в правильном порядке, и передает этот поток дальше для обработки соответствующим протоколом верхнего уровня. Сравнение идентификаторов дейтаграмм и выяснение соответствующей информации по флагам Last и More бита 2 позволяют хосту-получателю определить момент, когда следует прекратить ожидание следующих дейтаграмм и начать сборку уже поступивших.

Поле смещения фрагмента  (Fragment Оffsеt), имеющее длину 13 битов, позволяет идентифицировать местоположение данной дейтаграммы в передаваемом потоке. Хост-получатель использует значение, указанное в этом поле, для определения очередности сборки совпадающих по полям идентификации дейтаграмм. Хост-отправитель всегда присваивает полю смещения фрагмента первой дейтаграммы значение 0. Каждая из последующих дейтаграмм имеет в поле смещения фрагмента значение, присваиваемое на основе размера MTU данного участка. По этим значениям хост-получатель собирает дейтаграммы в определенной последовательности по мере их поступления; эти же значения позволяют обнаружить отсутствие одной из дейтаграмм. В приведенном ниже примере рассматривается процесс передачи хостом-отправителем трех дейтаграмм, принадлежащих одному и тому же потоку. При этом хост-отправитель выполняет следующие действия:    

   1. Присваивает каждой дейтаграмме один и тот же идентификатор.

             2. Устанавливает флаг Моrе Fragments  в 1(Есть еще фрагменты) в первых двух дейтаграммах, чтобы указать, что в данном потоке есть другие дейтаграммы.

            3. Устанавливает флаг Last Fragments (Последний фрагмент) в третей дейтаграмме, чтобы указать, что данная дейтаграмма является последней в потоке данных.

            4. В поле смещения фрагмента каждой из дейтаграмм устанавливает значение, определяющее местоположение данной дейтаграммы в передаваемом потоке.

На рис. 7 изображено, как хост-отправитель и хост-получатель применяют значение поля смещения фрагмента для определения очередности сборки дейтаграмм. Как показано на этом рисунке, станция А имеет намерение передать данные на станцию Б и отсылает по линии связи единственную дейтаграмму, содержащую 1500 байтов информации. Следует обратить внимание на то, что размер максимального модуля передачи (MTU) участка локальной сети, на котором расположен хост А, равен 1518 байтам. Следовательно, данный участок позволяет выполнить пересылку кадра, содержащего дейтаграмму размером 1500 байтов. Дейтаграмма поступает в маршрутизатор 1, который пересылает ее маршрутизатору  2 в первоначальном виде, поскольку MTU участка сети между этими маршрутизаторами также имеет размер 1518 байтов. Согласно изображению на рис. 2.3 участок глобальной сети между маршрутизаторами 2 и 3 не примет сегмент данных, размер которого больше 512 байтов. Из этого следует, что маршрутизатор 2 должен разбить исходную дейтаграмму, отправленную хостом А, на более мелкие части, приспособив ее таким образом к пересылке по данной линии связи. Эта процедура разбиения исходной дейтаграммы на части и называется фрагментацией (Fragmentation). Теперь имеется три фрагмента дейтаграммы, каждый из которых передается на маршрутизатор 3, и в конечном счете — на хост Б, т.е. в пункт назначения. Как только все фрагменты исходной дейтаграммы достигают хоста Б, этот хост выполняет сборку дейтаграммы перед тем как передать их для дальнейшей обработки на верхний уровень.

Хост Б (хост-получатель) использует значения, указанные в поле идентификации, полефлагов и поле смещения фрагмента, для сборки дейтаграммы в ее первоначальном виде.

                     Рис.7. Фрагментация   и  сборка дейтаграмм.

       Согласно примеру, приведенному на рис. 2.3 хост-получатель рассчитывает получить фрагменты дейтаграммы и собрать их в следующем порядке:

        1. Первым фрагментом передаваемого потока является фрагмент, значение поля смещения которого равно 0.

       2. Второй фрагмент имеет поле смещения со значением 512.

       3. Третий фрагмент имеет поле смещения со значением 1024. Хост-получатель хранит дейтаграммы в своем буфере в ожидании сообщений, поступающих вместе с потоком данных. При этом дейтаграммы могут поступать на хост-получатель в произвольном порядке. Если в указанном выше примере первым поступит второй фрагмент, имеющий поле смещения со значением 512, хост-получатель знает, что ему следует ожидать поступления других фрагментов, поскольку:

· Хост-отправитель пометил данный фрагмент как "Моrе, Есть еще фрагменты".

·  Данный фрагмент не яатяется последним, поскольку он не помечен как Last, Последний фрагмент".

·  Хост-получатель еще не принял фрагмент дейтаграммы, значение поля смешения которого равно 0. а это означает, что еще не получен первый фрагмент. Хост назначения уже получил фрагмент дейтаграммы с установленным флагом Моrе (Есть еще фрагменты), и еще не получил фрагмент, помеченный флагом Last (Последний фрагмент). Из этого можно сделать вывод, что ожидается дальнейшее поступление других дейтаграмм. Как только хост-получатель примет все фрагменты данного потока, он может собрать их в правильной последовательности и передать на верхний уровень для дальнейшей обработки соответствующим приложением.

Поле времени жизни: Значение поля времени жизни (TTL, Time To Live), имеет длину 1 байт, и каждое устройство, обрабатывающее дейтаграмму, уменьшает (обычно на единицу) измеряемое в секундах значение поля времени жизни. Установка определенного значения TTL имеет своей целью:

• Определить максимальное время присутствия дейтаграммы в Интернете перед ее отбрасыванием.

• Обеспечить отбрасывание дейтаграмм, которые по какой-либо причине не могут быть доставлены адресату.

В поле типа протокола (Protocol), имеющем длину 1 байт, указывается значение, определяющее тип следующего (верхнего) протокола, который предполагается использовать для дальнейшей пересылки данной дейтаграммы. Поле типа протокола может принимать одно из следующих значений:

• 06 (TCP, Transmission Control Protocol, Протокол управления передачей)

• 17 (UDP, User Datagram Protocol, Протокол доставки дейтаграмм пользователя)

Протокол IP использует эти значения для определения типа протокола верхнего уровня, которому IP должен передать полученные им данные для дальнейшей обработки

Поле контрольной суммы заголовка. Поскольку IP — не ориентированный на соединение протокол, в нем не реализован ни один из механизмов исправления ошибок (error correction mechanism), таких как упорядочивание передаваемых сегментов данных (sequencing) и выдача подтверждений их получения (acknowledgment). Протокол IP просто адресует дейтаграммы и отсылает их с надеждой на то, что они достигнут адресата. Поэтому IP применяет простое вычисление контрольной суммы (checksum), указанной в данном поле длиной 2 байта, для проверки целостности заголовка дейтаграммы IP и содержащихся в этой дейтаграмме данных. Пересчет контрольной суммы позволяет убедиться, что ни один из битов не был поврежден во время пересылки между двумя конечными хост-компьютерами. Промежуточные устройства должны пересчитывать и проверять значение поля контрольной суммы в каждом пункте обработки дейтаграммы, поскольку некоторые поля заголовка IP изменяются во время перемещения дейтаграммы по сети (например, значение поля времени жизни).

Поле адреса отправителя. Хост-отправитель устанавливает свой логический адрес сетевого уровня, т.е. IP-адрес (logical Network layer address, IP-address) в поле адреса отправителя (Source Address). Это поле имеет длину 4 байта; указанное в нем значение однозначно идентифицирует отправителя дейтаграммы.

В поле адреса получателя (Destination Address), имеющем длину 4 байта, указывается логический адрес хоста-получателя на сетевом уровне (logical Network layer address, IP- address). Этот логический 32-разрадный IP-адрес идентифицирует хост назначения и сеть, в которой он находится.

Хосты или шлюзы могут реализовать в заголовке IP необходимые им дополнительные параметры. Установить их можно в поле дополнительных параметров (Options), которое может иметь переменную длину. Наличие поля дополнительных параметров в заголовке дейтаграммы IP носит необязательный характер, однако, если это поле активизировано — все хосты и шлюзы, обрабатывающие дейтаграмму, должны быть в состоянии распознавать и поддерживать его. В поле дополнительных параметров может быть указан параметр уровня безопасности (security option), если активизирован один из битов приоритета поля ToS.

Поле заполнения. Протокол IР использует это поле переменной длины, когда заголовок IP не заканчивается на 32-разрядной границе. Поле заполнения (Padding) предназначено для того, чтобы выровнять заголовок IP (путем заполнения служебным двоичным кодом) по 32-разрядной границе, поскольку длина заголовка IP исчисляется в 32-разрядных словах.

.  ПРОЦЕСС УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ В ПРОТОКОЛЕ  TCP

2.1 Установление логических соединений в  протоколе   ТСР

      ТСР — это единственный ориентированный на соединение протокол, который входит в состав стека протоколов ТСР/IР на транспортном уровне. Решение об использовании приложениями протокола ТСР в качестве протокола транспортного уровня принимается в зависимости от того, есть ли необходимость в функциях, предоставляемых данным протоколом. Где бы ни находились ориентированные на соединение протоколы, — на транспортном или любом другом уровне, — им всегда свойственны шесть основных характеристик:

·  Установление сеанса связи (session setup) — создание виртуального канала связи между двумя коммуникационными процессами (процессами передачи данных), выполняемыми конечными хост-компьютерами

·  Формирование подтверждений (asknowledgements ,ACK) — уведомлений хоста-отправителя о том, что переданные им данные получены.

·  Упорядочивание сегментов данных (sequencing — присвоение порядкового номера каждому передаваемому сегменту для упорядочивания передаваемых датаграмм.

·  Управление потоком (Flow Contrl) — управление скоростью передачи данных. Конечные хосты могут обмениваться друг с другом запросами на увеличение или уменьшении скорости передачи данных.

·  Формирование сообщений о поддержании соединения (Kеераlivеs) — поддержание соединения активным в то время, когда не происходит передача данных.

· Завершение сеанса связи (Session teardown ) —выполняется, когда любая из конечных систем инициирует разрыв виртуального соединения Установление ориентированного на создание соединения сеанса связи всегда начинается на нижних уровнях и достигает верхних уровней модели ОSI.

         При любом обращении приложения к ТСР этот протокол создает виртуальное соединение еще до того, как начнется процесс передачи какой бы то ни было значащей информации. Как только нижние уровни установят связь с верхними уровнями, через это соединение можно начинать пересылку данных между приложениями. ТСР использует трехшаговый обмен сообщениями для установления сеанса связи. Чтобы обеспечить сохранность данных во время передачи, ориентированные на соединение протоколы обмениваются порядковыми номерами (sequence numbers), присвоенными каждому сегменту, а также номерами подтверждений (acknowledgement numbers) доставки передаваемых сегментов. У каждого протокола существует свой способ присвоения порядковых номеров. Некоторые протоколы присваивают такие номера каждому кадру (Frame), другие — присваивают их каждому байту в пределах кадра. Однако каким бы ни был сам метод, задача остается одной и той же: обнаружить потерянные данные или кадры и, если есть такие, восстановить их посредством повторной передачи данных. Когда хосты бездействуют (не обмениваются данными), необходимость в поддержании виртуального соединения по-прежнему существует. Эта функция реализуется через применение сообщений о поддержании соединения активным (кеерalives) — кратких сообщений, которыми два хоста обмениваются для подтверждения необходимости в продолжении сеанса связи. Подобные сообщения гарантируют поддержание виртуального соединения в то время, когда процесс, выполняемый на хосте, временно приостановлен. Сообщения такого типа не используются для передачи данных приложениями верхнего уровня; хосты отсылают такие сообщения только для того, чтобы обеспечить поддержание соединения. Протокол IР является дейтаграммным протоколом и поэтому по своей природе не может гарантировать надежность передачи данных. Эту задачу- обеспечение надежного канала обмена данными между прикладными процессами в составной сети — решает протокол ТСР (Тrаnsmission Control Protocol), относящийся к транспортному уровню.

        Протокол ТСР работает непосредственно над протоколом IР и использует для транспортировки своих блоков данных потенциально ненадежный протокол IР. Надежность передачи данных протоколом ТСР достигается за счет того, что он основан на установлении логических соединений между взаимодействующими процессами. До тех пор пока программы протокола ТСР продолжают функционировать корректно, а составная сеть не распалась на несвязные части, ошибки в передаче данных на уровне протокола IР не будут влиять на правильное получение данных.                      

 Протокол  IР используется протоколом ТСР в качестве транспортного средства. Перед отправкой своих блоков данных протокол ТСР помещает их в оболочку IР-пакета. При необходимости протокол IР осуществляет любую фрагментацию и сборку блоков данных ТСР, требующуюся для осуществления передачи и доставки через множество сетей и промежуточных шлюзов используют для передачи сообщений дейтаграммный протокол IР.

Рис. 8.TCP-соединение создает надежный канал связи между

конечными узлами.

 На рис. 8 показано, как процессы, выполняющиеся на двух конечных узлах, устанавливают с помощью протокола ТСР надежную связь через составную сеть, все узлы которой используют для передачи сообщений дейтаграммный протокол IР.

          Основные механизмы протокола ТСР

           Для обеспечения надежной доставки данных в пункт назначения протокол ТСР предусматривает наличие двунаправленного канала передачи данных (Bidirectional communication pipe) между удаленными процессами. Такой двунаправленный канал идентифицируется соответствующими номерами портов ТСР на конечных хостах. Как утверждается в КРС 793, протокол ТСР регулирует процесс взаимодействия между удаленными процессами с помощью следующих имеющихся в его распоряжении возможностей:

· Установление соединения ( Connection Setup)

· Закрытие соединения (Connection teardown)

· Мультиплексирование (Multiplexing)

· Передача данных (Date transfer)

· Управление потоком (Flow control)

· Надежность (Reliability)

· Приоритет (рrесеdence) и защита данных (security)

        Протокол ТСР выполняет гарантированную доставку данных в пункт назначения, и, безусловно он делает это намного быстрее, чем доставка корреспонденции по Fed-ЕХ (Fed-ЕХ –Federal Express, Федеральная служба доставки почты). С другой стороны, протокол ТСР выполняет передачу данных медленнее, чем протокол UDP, который, в свою очередь, совсем не обеспечивает надежности доставки данных. Достижение протоколом ТСР свойственного ему высокого уровня надежности доставки данных в пункт назначения влечет за собой рост непроизводительных затрат, связанных с установлением, поддержанием и завершением сеансов связи между хостами. 

           В отличие от не ориентированных на соединение проколов, ТСР не возлагает ответственность за прокладывание пути для прохождения данных на протоколы верхних уровней. Протокол ТСР не ограничивается одной лишь идентификацией выполняемых на хосте-отправителе и хосте-получателе процессов, только помещая данные в канал связи с надеждой на то, что эти данные достигнут пункта назначения без дальнейшего вмешательства ТСР. Для обеспечения гарантированной доставки ТСР-пакетов в пункт назначения протокол ТСР использует такие процедуры, как упорядочивание передаваемых сегментов данных (sequencing) и выдача подтверждений об их получении (ackowledgements). В отличие от протокола UDP, выполняющего сходные с ТСР функции, протокол ТСР при получении потока данных (сообщений) разбивает этот поток на сегменты (сегментирует его) и присваивает порядковый номер (sequence number) каждому передаваемому сегменту данных перед доставкой данных в пункт назначения в дейтаграмме IР. Для обеспечения гарантированной доставки каждого отправленного хостом-отправителем сегмента протокол ТСР предусматривает выдачу подтверждения приема каждого сегмента дейтаграммы, имеющего порядковый номер. Протокол ТСР хранит копии всех передаваемых сегментов данных в буфере ЗУ хоста-отправителя, известном под названием "Блок управления передачей данных" (ТСВ, Trancmission Control block). Если ТСР не получает подтверждения приема данных, он делает предположение, что дейтаграмма потеряна, и выполняет ее повторную пересылку.

Установление и закрытие соединения

        Обязательным условием гарантированной доставки данных между удаленными процессами является установление протоколом ТСР соединения между хостами (Connection setup) еще до начала обмена значащими данными между приложениями верхнего уровня. Для выполнения этой задачи протокол ТСР прежде всего устанавливает между портами удаленных хостов так называемое "логическое соединение — Logical circuit. Такое соединение связывает порты или процессы, выполняющиеся на каждом из двух конечных хостов. ТСР поддерживает это соединение на протяжении всего сеанса связи и закрывает его (Connection Teardown), когда отпадает необходимость в дальнейшем поддержании соединения. Протокол ТСР устанавливает сеанс связи между удаленными хостами сразу же после выяснения протоколом IР логического адреса хоста назначения. Установленный протоколом ТСР сеанс связи является для протоколов верхнего уровня надежной базой для обеспечения гарантированной доставки данных в пункт назначения. Протокол ТСР завершает сеанс связи, когда пользователь или один из хостов инициирует завершение этого сеанса связи. Процедура установления (Session setup) и завершения (Session teardown) сеансов связи,

Мультиплексирование

           Возможность мультиплексной передачи данных (Multiplexing) позволяет протоколу ТСР устанавливать и поддерживать одновременно несколько коммуникационных путей между двумя хостами. Мультиплексирование позволяет также одному хосту дифференцировать и поддерживать сеансы связи с несколькими хостами в одно и то же время. Возможность мультиплексной передачи данных чрезвычайно важна для хостов, поскольку на них, как правило, выполняется несколько приложений или служб, таких как Telnet, FТР или другие службы. Протокол ТСР должен иметь возможность отличить один процесс от другого, а также координировать и обслуживать коммуникационный процесс для каждого из этих процессов.

       Для выполнения упомянутой выше задачи протокол ТСР использует порты, позволяющие дифференцировать коммуникации между рахтичными процессами и координировать их (более подробную информацию о мультиплексоре обслуживания ТСР-портов ТСРМUХ можно найти в КРС 1078). Как упоминалось в главе 6, существует два ОСНОБных типа портов: порты серверов (Server Ports) и порты клиентов (Client ports). Порты серверов идентифицируют основные приложения и службы (например, Теlnet — порт 23, SМТР — порт 25, FТР — порты 20, 21). Порты клиентов не присваиваются на постоянной основе; они выбираются оперативно и применяются динамически. Номера портов клиентов находятся в диапазоне от 1024 до 65535.

        Каждый раз, когда хост активизирует выполнение какого-либо процесса, это вызывает открытие одного из портов, а также выделение этому процессу определенных ресурсов. Когда у процесса отпадает необходимость в использовании порта, он закрывает этот порт и освобождает выделенные ему через этот порт ресурсы для их перераспределения между другими процессами. Протокол ТСР использует порты для идентифика¬ции пары процессов, выполняемых хостом-отправителем и хостом-получателем. Выделенный тому или иному хосту порт вместе с логическим IР-адресом сетевого уровня (в коммуникационной модели организации сетевого комплекса DoD) образует так называемый сокет (socket), который, в свою очередь, однозначно идентифицирует выполняемый на хосте процесс. После установления ТСР-соединения между двумя удаленными хостами соответствующие этим хостам сокеты образуют пару сокетов (Socket pair), которая и формирует соединение между локальными процессами, выполняемыми на конечных хостах.. Образование пар сокетов позволяет хосту дифференцировать соединения, связывающие данный хост с различными процсесами одного и того хоста, или с разными хостами.

Передача данных

            Протокол ТСР получает данные от приложений верхних уровней, сегментирует их и передает на нижний уровень для формирования из полученных сегментов данных IР-дейтаграмм, а также их адресации, пакетирования и доставки в пункт назначения протоколом IР на сетевом уровне. Когда протокол IР получает дейтаграммы от удаленного хоста, он исследует указанный в заголовке IР адрес верхнего уровня для того, чтобы определить, через какой протокол (ТСР или UDP) он должен передать полученную дейтаграмму для ее дальнейшей обработки.

          Протокол ТСР функционирует на базе протокола Интернета (IР), который обеспечивает адресацию дейтаграмм на сетевом уровне, а также доставку дейтаграмм между конечными хостами без создания соединения. Значение 06, указанное в поле типа протокола (Рrotocol) заголовка IР, идентифицирует протокол ТСР. Значение 17. указанное в том же поле заголовка IР, соответствует протоколу UDР. Когда ТСР получает от протокола IР дейтаграммы, содержащие сегменты данных, он выполняет их повторную сборку (Reassembly) в упорядоченные потоки данных (сообщения), определяет принимающий порт клиента или сервера и передает эта 1ютоки данных соответствующему приложению (верхнего уровня) для дальнейшей обработки. Между приложениями верхнего уровня и протоколом Интернета нижнего уровня устанавливается двунаправленное взаимодействие, направление которого зависит от того, куда передвигается поток данных. Протокол ТСР предоставляет одни и те же услуги всем протоколам верхнего. В текущем разделе данной главе" представлено весьма упрошенное описание действия протокола ТСР.

Управление потоком

           Для обеспечения доставки данных в пункт назначения протоколу ТСР необходимо иметь в своем распоряжении какой-либо способ регулирования входящего потока данных. Применение механизма управления потоком (Flow contrl) гарантирует отсутствие переполнения принимающего буфера хоста-получателя. Управление потоком также предоставляет хосту-получателю возможность соответствующим образом обрабатывать полученные данные и отвечать на запросы хоста-отправителя. Функция регулирования потока данных поддерживается с помощью оконного механизма передачи данных (Window Mechanism), идентифицированного в соответствующем поле заголовка ТСР.  Каждый конечный хост обслуживает свое собственное окно и информирует другую сторону о состоянии этого окна. Когда окно заполняется, хост сокращает размер окна и сообщает об этом партнеру по коммуникации. Тем самым хост, в сущности, отправляет в адрес противоположной стороны запрос на снижение скорости передачи данных.

          Когда приемное окно не перегружено данными, хост может увеличить размер окна, сообщая партнеру по коммуникации о возможности дальнейшей пересылки данных. Окно, размеры которого можно увеличивать или уменьшать динамическим способом, называется скользящим окном (Sliding window). Сетевой администратор имеет возможность сконфигурировать начальный размер имеющегося у хоста окна. Этот размер меняется в зависимости от используемой на том или ином хосте операционной системы.

Надежность

               Надежность передачи данных протоколом ТСР является результатом применения этим протоколом определенных механизмов обеспечения гарантированной доставки пакетов в пункт назначения. В число этих механизмов входит упорядочивание каждого сегмента отправленных данных (sequencing), а также выдача соответствующего подтвер¬ждения со стороны получателя (АСК, acknowledgement) о получении каждого сегмента. Такой способ организации передачи данных позволяет хосту обнаружить потерю информации или передачу ее в неверном порядке.

        Хост-получатель не отправляет АСК в случае потери дейтаграммы в процессе передачи. Задача обнаружения потерянных или отсутствующих кадров, а также задача повторной их пересылки в случае необходимости возлагается на хост — источник данных (хост-отправитель). Если отправитель данных не получает подтверждения о получении на протяжении определенного периода времени, он восстанавливает эти данные с помошью хранящейся в буфере ТСВ копии и выполняет повторную пересылку потерянных сегментов данных. Период времени, выделяемого на обнаружение потерянного кадра и его повторную пересылку, задается специально сконфигурированным на хосте-отправителе таймером. Устанавливаемое в таком таймере значение вычисляется на основе задержки, равной времени полного обхода (Round-trip DOI). И если время в таймере истекает до получения подтверждения, то хост-отправитель считает, что дейтаграмма потеряна, и повторяет передачу этой дейтаграммы. Протокол ТСР решает вопрос обнаружения поврежденных кадров посредством содержащегося в заголовке ТСР поля СRС (Cycliс Redundancy Check) . Проверка целостности данных при помощи избыточного циклического кода). Перед передачей данных хост-отправитель выполняет вычисление контрольной суммы на основе алгоритма СКС. После получения данных хост-получатель посредством того же алгоритма также вычисляет контрольную сумму. Совпадение или несовпадение этих двух значений позволяет определить, была ли дейтаграмма повреждена во время пересылки. Если хост-получатель фиксирует повреждение дейтаграммы, он просто отбрасывает кадр, не предупреждая об этом хост-отправитель. По прошествии определенного периода времени хост-отправитель обнаруживает возникновение проблемы с передачей кадра, поскольку от хоста-получателя не поступило соответствующего подтверждения. Именно на данном этапе истекает значение таймера ТСР, что побуждает хост-отправитель выполнить повторную передачу данных.

Приоритет и защита данных

           Обязательным требованием, предъявляемым Министерством Обороны США к реализации в его сетях какого бы то ни было протокола, является поддержка этим протокол им многоуровневой модели зашиты данных от несанкционированного доступа (Multilevel Security Model), а также поддержка передачи данных согласно различным уровням приоритета (Precedence leves). Протокол ТСР имеет возможность использовать значения, устанавливаемые в поле типа обслуживания (Туре оf service) заголовка IР, для обеспечения требуемого приложением верхнего уровня типа обслуживания и способа защиты данных. Соответственно этим опциям протокол ТСР обеспечивает процесс передачи данных для приложений верхних уровней согласно следующим характеристикам:

• Приоритет (Precedence)

• Задержка (Delay)

• Производительность(Throughput)

• Надежность (Reliability)

      Параметры, указанные в поле типа обслуживания (Туре оf Service) заголовка IР указывают на то. каким образом следует-выполнять передачу дейтаграммы. В случае реализации устанавливаемых в поле типа сервиса параметров (приоритет, задержка, производительность и надежность) эти параметры оказывают влияние на выбор маршрута для доставки дейтаграмм в пункт назначения. Например, если приложению необходима доставка дейтаграммы по самому быстродействующему каналу, в случае наличия нескольких путей к пункту назначения это приложение может потребовать от маршрутизаторов переслать соответствующий кадр по пути с минимальной задержкой.

           Первый устанавливаемый в поле типа обслуживания (ТоS) параметр, известный как приоритет передаваемых данных (Precedence), указывает на то, какую информацию содержит дейтаграмма: с обычным или высоким уровнем приоритета. От уровня приоритета зависит и уровень защиты данных (Security Level ): чем выше приоритет, тем выше уровень защиты. Хост с некорректно установленным или более низким уровнем приоритета (уровнем защиты данных) не может установить соединение с другим-хостом, имеющим более высокий уровень приоритета. В связи со сложившимся несовпадением уровней приоритета хост отклоняет запрос другого хоста на установление соединения, основывая свое решение на требованиях многоуровневой системы защиты данных. В отличие от протокола IР, также содержащего параметры типа сервиса в поле ТоS заголовка IР, протокол ТСР может активизировать эти функции при каждом установлении соединения посредством двунаправленного процесса коммуникации между двумя конечными хостами. ТСР имеет возможность хранить значения типов сервиса в соответствующем буфере ЗУ с целью обеспечения усиленной защиты данных от несанкционированного доступа, а также для обеспечения более результативной доставки данных между приложениями.

2.2. Процесс установления TCP-соединения.

Все протоколы, входящие в состав стека протоколов ТСР/IР, можно разделить на две категории: ориентированные на соединение и не ориентированные на соединение протоколы. Поскольку ТСР принадлежит к категории ориентированных на соединение протоколов, в нем реализованы следующие шесть базовые средства обеспечения гарантированной доставки данных в пункт назначения:

• Установление сеанса связи (session setup)

• Завершение сеанса связи (Session tear down)

• Упорядочивание передаваемых данных(sequencing)

• Выдача подтверждений о получении (ackowledgements)

• Поддержание соединения активным (Keepalives)

• Управление потоком данных (Flow control)

Установление сеанса связи

          Для обеспечения гарантированной доставки данных между удаленными процессами или приложениями необходимо установить надежное, ориентированное на установление соединения логическое соединение (Relable connection oriented logical circuit ) между этими процессами или приложениями. Такое логическое соединение должно быть установлено еще до начала передачи данных. Процедура установления сеанса связи (Session setup) остается неизменной независимо оттого, какой процесс этот сеанс связи должен обслуживать. В распоряжении протокола ТСР имеется средство, позволяющее уникальным образом идентифицировать все процессы и приложения верхнего уровня: использование адреса портов (роrts) или сокетов (Sоскеts). Каждому процессу, который выполняется на том или ином хосте, соответствует отдельный порт. Следовательно, по номерам портов протокол ТСР имеет возможность отличать выполняемые на одном и том же хосте процессы друг от друга. Такая дифференциация процессов по номерам их портов обеспечивает гарантированную доставку данных между удаленными процессами и их обработку надлежащим образом.

Завершение сеанса связи

            Запрос на завершение сеанса связи (Session teardown) может исходить либо от самого пользователя, либо от протокола ТСР. Если пользователь больше не нуждается в услугах удаленного приложения, он может выйти из локального приложения, инициируя тем самым выдачу запроса на завершение сеанса связи (Session teardown request). Процедура завершения сеанса связи аналогична процедуре установления сеанса. Протокол ТСР использует для закрытия сеанса связи такой же трехэтапный обмен кадрами (Three- frame exchange). Инициировать завершение сеанса связи может любая из взаимодействующих сторон. Хост 192.42.252.1 (порядковый номер 49856607) отправляет начальный запрос на Получатель отправляет свое подтверждение (АСК) о приеме запроса, содержащего заключительный сегмент (FIN), с указанием порядкового номера сегмента, который он ожидает получить следующим (49856608). Кроме того, хост-получатель отправляет свой собственный запрос на завершение сеанса (FIN), а также порядковый номер (1545216061). Хост — инициатор завершения сеанса связи отправляет последний кадр, подтверждающий получение предыдущего запроса FIN. Это действие закрывает соединение, после чего хосты не могут обмениваться информацией приложений верхних уровней до тех пор, пока не будет установлен новый сеанс связи ТСР. Протокол ТСР также отправляет подобный запрос на завершение сеанса связи в случае обнаружения ошибки или отказа в доступе во время установления сеанса связи ТСР. 

Упорядочивание и подтверждение кадров

   Максимальная надежность передачи данных между хостами — это задача первостепенной важности для предоставляемых протоколом ТСР служб. Чтобы обеспечу  гарантированную доставку данных в пункт назначения, ТСР присваивает порядковый  номер каждому передаваемому им сегменту данных (эта процедура называется упорядочиванием — sequencing). С одной стороны, такой подход к передаче данных М показаться избыточным, поскольку многие протоколы присваивают порядковый номер  каждой дейтаграмме независимо от того, какой объем данных в ней передается. Одна ко, с другой стороны, этот подход позволяет проконтролировать передачу каждого отправленного байта данных в пункт назначения. Отслеживание всех отправленных данных {tracking) позволяет обнаружить и устранить проблемы, связанные с потерей данных  (lost data ), с дублированием данных (duplicate data) или с доставкой данных не в тс рядке, в котором они были отправлены (data delivered out of order).

Каждый раз, когда хост отправляет данные в адрес партнера по коммуникации, протокол ТСР присваивает порядковый номер (sequence number) каждому отправленное сегменту данных.

Поддержание соединения активным

Каждый ориентированный на установление соединения протокол нуждается в наличии какого-либо способа сохранения логического соединения между двумя взаимодействую общими процессами даже в то время, когда между этими процессами не происходит сохранения  логического соединения в рабочем состоянии ТСР оправляет дейтаграмму, содержащую сообщение о поддержании соединения активным (keepalive). В такой дейтаграмме  нет данных приложений верхнего уровня. Протокол ТСР использует дейтаграммы такого типа исключительно для поддержания сеанса связи в активном состоянии; отсюда происходит и само название: "сообщения о поддержании соединения Активным (keepalive)". Поскольку передающий сообщения такого типа кадр не содержит никаких значащих данных, в поле длины кадра (Length) установлено значение 0  из чего следует, что передача данного кадра не требует подтверждения о получении.

          Возникновение одной из этих проблем стимулирует либо клиентский, либо серверный ТСР-процесс выдать запрос на закрытие соединения. Какой бы ни была причина, завершение сеанса связи всегда выполняется посредством процедуры трехходового квитирования. Так же, как и в случае установления сеанса связи, во время завершения сеанса используется трехэтапный обмен кадрами. Хост, запрашивающий закрытие сеанса, устанавливает бит завершения передачи (FIN) в поле флагов (Рlags) заголовка ТСР, указывая тем самым на то, что данное сообщение содержит запрос на завершение сеанса связи. Далее выполняется передача заключительного сегмента (FIN) партнеру по коммуникации. Получатель должен, в свою очередь.

Управление потоком

             Управление потоком (Flow control) — это функция имеющегося в распоряжении ТСР оконного механизма передачи данных (WINDOW MECHANISM). Протокол ТСР использует управление потоком с целью ограничения объема данных, поступающих в буфер получателя и, следовательно, для предотвращения переполнения буфера. Если хост-отправитель передает данные быстрее, чем хост-получатель может их принять, получатель направляет в адрес отправителя запрос на снижение скорости передачи данных и на сокращение объема данных до тех пор, пока не освободится его буфер.

         В некоторых случаях хост-получатель принимает слишком большой объем данных, переполняющий буфер. При возникновении такой ситуации получатель отсылает блокирующий пакет (Choke packet), предписывающий отправителю полностью прекратить передачу данных. Если ситуация достигает критического уровня, это даже может стать причиной завершения сеанса связи. В состав заголовка ТСР,входит поле под названием "Окно" (Window). При каждом обмене кадрами, включая установление сеанса связи (обмен кадрами синхронизации SYN), каждый партнер по коммуникации сообщает другой стороне текущий размер своего приемного буфера.  

         Рассмотрим пример работы механизма управления потоком. Один из взаимодействующих хостов объявляет в своем начальном кадре синхронизации (SYN), что он может принять 4096 байт данных (в заголовке ТСР это утверждение выражено строкой WIN=4096). Из этого следует, что другой хост, функционирующий на равных правах указанным хостом, не может пересылать в его адрес больше чем 4096 байт данных. Размер окна отправки (Send window) одного из хостов, принимающих участие в процессе коммуникации на равных правах, автоматически становится эквивалентным размеру приемного окна (Receivе window) партнера по коммуникации. Это означает, что отправитель не может переспать больший объем данных, чем получатель может принять. После начальной синхронизации в каждом передаваемом кадре указывается текущий размер (в байтах) приемного окна хоста.

             Взаимодействующие между собой хосты имеют возможность регулировать размер окна, указывая в последующих кадрах меньший размер буфера (в случае его перегрузки) или больший размер буфера (в случае уменьшения нагрузки). Например, если хост предпринимает попытку поддерживать сеансы связи с несколькими клиентами, он может быстро исчерпать свои ресурсы. В таком случае возникает необходимость управления потоком данных посредством уменьшения размера части окон ТСР, через которые выполняется обмен данными по соединениям с некоторыми клиентами. Управление потоком данных позволяет хосту своевременно выполнять корректную и эффективную обработку данных, которые он получает от всех других взаимодействующих с ним хостов. В случае отсутствия в составе возможностей протокола ТСР какого-либо механизма контроля над перегрузкой приемного буфера некоторые сеансы связи могли бы целиком захватить ресурсы того или иного хоста. Такое развитие событии, в свою очередь, привело бы к закрытию сеансов связи других клиентов по истечении тайм-аута. Оконный механизм передачи данных позволяет протоколу ТСР регулировать поступление трафика от сеанса связи ТСР (функции оконного механизма в данном контексте очень похожи на функции полицейского, регулирующего уличное движение). С помощью этого механизма протокол ТСР увеличивает размер окна при наличии достаточного количества ресурсов для обработки запросов (входящему трафику "дается зеленный свет"). Аналогично размер окна уменьшается, когда происходит переполнение буфера; тем самым хост-получатель направляет в адрес хоста-отправителя запрос на уменьшение скорости передачи данных (входящему трафику "дается желтый свет"). Поступление трафика прекращается полностью в случае критической перегрузки буфера; при этом в блокирующем пакете размер окна объявляется равным 0 (хосту-отправителю "дается красный свет", предписывающий ему полностью прекратить передачу данных).. Следует обратить внимание на то, что если даже размер приемного окна хоста равен 0, этот хост все же поддерживает передачу данных. Однако в таком случае он может принимать только критические кадры, а именно кадры, содержащие подтверждения (АСК), и кадры с установленными в поле флагов (Flags) битами RSТ (флаг переустановки соединения) или URG (флаг срочности).

Порты ТСР

Для установления отношений клиент-сервер протокол ТСР использует общеизвестные порты (Wel-known ports). Эти порты используются протоколом ТСР на транспортном уровне с целью идентификации процессов верхних уровней, которые передают потоки данных или должны их принять.

Установка соединения

              Протокол ТСР ориентирован на соединение. Это означает, что до начала обмена данными прикладного уровня две системы должны установить связь между собой — это гарантирует, что оба компьютера существуют, работают без сбоев и готовы к приему данных. Соединение ТСР сохраняется на протяжении всего обмена данными, а затем закрывается установленным образом.

        В большинстве случаев соединение ТСР устанавливается на время передачи единственного файла. Например, подключаясь к серверу в Интернете, браузер сначала устанавливает соединение с ним, затем передает НТТР-запрос   с URL и наконец получает файл, указанный в URL. Как только файл передан, системы разрывают соединение. Обрабатывая полученный файл, браузер может найти в нем ссылки на изображения, звукозаписи и другие файлы, необходимые для отображения Web-страницы. Для каждого из них браузер устанавливает новое соединение с сервером, копирует файл и отображает его в составе страницы. Таким образом, обработка одной Web-страницы может обернуться десятком самостоятельных ТСР-соединений. Процесс установления ТСР-соединения называется трехшаговым рукопожатием (three-way handshake) (рис.9) и состоит из обмена тремя сообщениями  ни одно из которых не содержит данных прикладного уровня. Помимо проверки существования другого компьютера и его готовности к приему данных, цель этих сообщений состоит в согласовании нумерации передаваемых сообщений. В начале соединения каждый компьютер выбирает для первого сообщения ТСР начальный номер последовательности (initial sequence number,ISN). Затем с каждым последующим сообщением системы увеличивают этот номер на 1

               Для выбора ISN компьютеры используют специальный алгоритм, который минимизирует вероятность того, что для соединения между одной и той же парой сокетов в одно и то же время будут
использованы одинаковые номера последовательности .

Рис 9.Для доставки TCP-соединения используется трехшаговое рукопожатие.

В сообщении с номером ISN для каждой системы установлен флаг синхронизации (SYN). В начале типичной ТСР-транзакции сообщение SYN с номером ISN в поле Sequence Number посылает клиентская система. Получив это сообщение, сервер генерирует ответ, который выполняет сразу две функции. Во-первых, за счет установки флага АСК ответное сообщение подтверждает получение первого клиентского сообщения SYN. Во-вторых, в отклике сервера также установлен флаг SYN, а в поле Sequence Number указан его номер ISN. Получив это сообщение, клиентская система генерирует свой собственный Отклике установленным флагом АСК. Как только сервер получил от клиента это подтверждение, соединение считается установленным и системы готовы обмениваться сообщениями с данными приложений. Таким образом, соединение ТСР на самом деле представляет собой два отдельных соединения, работающих в противоположных направлениях. ТСР является полнодуплексным протоколом: оба соединения устанавливаются и разрываются независимо друг от друга.

Передача данных

             После установки соединения у каждого компьютера есть вся необходимая для передачи прикладных данных информация. Вот из чего она складывается.

 • Номер порта. Клиенту уже известен номер порта сервера, который относится к хорошо известным портам и необходим для инициализации соединения. В поле Source Port сообщений клиента, адресованных серверу, передается временный номер порта, который будет подставляться в ответы сервера.

 • Номер в последовательности. В поле Acknowledgment Number сообщений каждая система подставляет номера в последовательности, предоставленные другой системой.

 • МSS. По значению дополнительного параметра МSS системы знают, насколько большими могут быть сегменты каждой последовательности. Очередность передачи данных зависит от типа приложения. Транзакция между браузером и Web-сервером обычно начинается с того, седьмого, приняты правильно, величина Acknowledgment Number в сообщении с подтверждением приема будет содержать число байтов только в первых шести сегментах. Хотя сегменты с восьмого по десятый и были приняты правильно, они будут проигнорированы, и следом за седьмым сегментом их нужно будет передать снова. Такая система называется положительным подтверждением с повторной переданей : целевая система подтверждает получение только тех сообщений, которые были приняты правильно. Возможно и отрицательное подтверждение, когда система-получатель извещает отправителя только о тех сообщениях, при передаче которых произошли ошибки. В системе-источнике поддерживается очередь переданных сообщений. Сообщения, для которых получено подтверждение приема, из нее удаляются. Сообщения, которые остаются в очереди на протяжении заданного промежутка времени, считаются утерянными, и система автоматически повторяет их передачу. Когда сервер передал все сегменты WеЬ-страницы, а клиент подтвердил их успешное получение, система разрывает соединение (процедура разрыва подробно описана ниже). Если сегменты поступили в целевую систему в неправильном порядке, она переставляет их, рукрводствуясь значениями Sequence Number. Затем клиентская система обрабатывает принятые данные и отображает WEB-страницу. Скоре е всего, страница будет содержать ссылки на изображения или другие элементы. Для их получения клиенту придется инициировать дополнительные соединения с сервером. Так производится обмен данными в WEB. Приложения других типов могут создавать единственное соединение ТСР и поддерживать его в течение длительного периода времени, неоднократно выполняя передачу данных и служебных сообщений в обоих направлениях.

Обнаружение ошибок

          Ошибки ТСР-транзакций можно разделить на две группы: сообщение совсем не достигает адресата или поступает к нему в испорченном виде. В, первом случае отсутствие подтверждения заставляет от правителя- повторить передачу. Если из-за серьезных проблем в сети обмен сообщениями между системами вообще невозможен, ТСР-соединение будет прервано, когда истечет срок его существования, и весь процесс придется начинать сначала. Когда сообщение прибывает по месту назначения, принимающая система проверяет его целостность, вычисляя контрольную сумму и сравнивая результат со значением в поле Checksum, которое было рассчитано и подставлено туда отправителем. Если два значения не совпадают, сообщение отбрасывается. Это очень важный момент ТСР-транзакции: только на этом этапе (и ни на каком другом) сравниваются «сквозные» контрольные суммы прикладных данных, вычисленные в начале и в конце передачи пакета. Протоколом IР тоже вычисляются сквозные контрольные суммы, но только для заголовка IР. Протоколы канального уровня, подобные Еthernet и Тоken Ring, вычисляют контрольные суммы для пакета целиком, но не сквозные, а только для одного перехода. Если пакетам на пути встретился переход без вычисления контрольной суммы, например, канал РРР, есть вероятность появления на нем ошибок, которые ни на канальном, ни на сетевом уровне

зарегистрированы не будут. Контрольная сумма, вычисляемая ТСР, не совсем обычна: она охватывает не только весь заголовок ТСР и прикладные данные, но также и псевдозаголовок (Pseudo-header), состоящий из полей IP-заголовка Sourceе IР Аddress,Protocol и Length, а также 1 байта заполнения, чтобы довести полное число байтов до 12 . Включение в контрольную сумму псевдозаголовка позволяет убедиться, что дейтаграмма доставлена на нужный компьютер и нужному протоколу транспортного уровня.

Управление потоком

             Управление потоком (flow control) заключается в том, что целевая система ТСР-соединения передает системе-источнику сведения, которые позволяют регулировать скорость передачи данных. В каждой системе предусмотрено некое ограниченное буферное пространство для хранения принимаемой информации.

        Данные остаются в буфере, пока система не отправит сообщение с подтверждением их приема. Если система-источник передает данные слишком быстро, буферы приемника переполняются, и информация начинает теряться. Во избежание этого принимающая система с помощью поля Window сообщений АСК информирует отправителя о том, сколько буферного пространства доступно в данный момент времени. Передающая система с помощью величин из полей Window и Acknowledgment Number определяет, какие данные последовательности ей можно передавать. Например, если в поле Acknowledgment Number сообщения АСК содержится число 150000, а значение поля Window равно 500, передающая система понимает, что данные последовательности до 150000 байта приняты успешно, и теперь можно передавать байты с 1150001 до 150500. Если к моменту окончания передачи этих 500 байтов дополнительные подтверждения приема все еще не получены, [передачу нужно приостановить до тех пор, пока они не придут. Такой способ управления потоком называется методом скользящего окна (Sliding Window). По мере того как принимающая система подтверждает прием байтов, левая граница окна сдвигается  вправо. Одновременно байты, прием которых подтвержден, передаются принимающей системой тому процессу прикладного уровня, номер порта которого указан в поле Destination Port. При этом правый край окна также сдвигается вправо. Таким образом, окно скользит вдоль потока входящих байтов слева направо.

Разрыв соединения

         Закончив обмен данными, системы, участвующие в ТСР-соединении, разрывают его с помощью управляющих сообщений, подобных тем, что использовались в трехшагоном рукопожатии. Которая из систем инициирует процесс разрыва, зависит от конкретного приложения. В случае обмена данными между клиентом и Web-сервером, который рассматривался выше, разрыв инициируется сервером, который в последнем сообщении с данными устанавливает флаг Fine в поле Соntrol Bits. В других случаях система, инициирующая разрыв, не может совмещать установленный флаг FIN с  отправкой данных и должна посылать для него отдельное сообщение.

Рис. 11. Разрыв TPC- соединения

            Система, принявшая флаг FIN, передает подтверждение его приема и генерирует собственное сообщение с установленным флагом FIN, на которое вторая система также откликается сообщением АСК (рис. 11). Выше уже говорилось, что соединение работает в обоих направлениях, и потому разорвать соединение должны обе системы. Комбинировать флаги АСК и Fine в одном и том же сообщении нельзя. Иногда соединение разрывается только в одном направлении. Такое соединение называется полузакрытым (Halt close).

Стандартная процедура установления связи представлена на рисунке 12  (под словом “стандартная” подразумевается отсутствие каких-либо отклонений от штатного режима, например, одновременного открывания соединения со стороны сервера и клиента). Если же соединение одновременно инициируется клиентом и сервером, в конечном итоге будет создан только один виртуальный канал.

Рис.12 Алгоритм установления связи. В рамках представлены состояния клиента и сервера; пунктиром отмечены изменения cостояния после посылки сообщения

Префикс S на рисунке указывает на сервер, а С - на клиента. Параметры в скобках обозначают относительные значения ISN. После установления соединения ISN(S) = s_seq_1, а ISN(C) = c_seq_1.

Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (established, closed, listen, syn_sent, syn_received и т.д см. также RFC-793), переход между которыми строго регламентирован.

Машина состояний для протокола TCP может быть описана диаграммой, представленной на рис. 12. Здесь состояние closed является начальной и конечной точкой последовательности переходов. Каждое соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни одному из состояний не поставлен в соответствие какой-либо таймер. Это означает, что машина состояний TCP может оставаться в любом из состояний сколь угодно долго. Исключение составляет keep-alive таймер, но его работа является опционной, а время по умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2 часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ посылают друг другу сигналы SYN. При поучении этого сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует посланному ранее SYN, они выключат таймер установления соединения и перейдут непосредственно в состояние syn_recvd (см. рис. 12).

В состоянии established пакет будет принят сервером, если его ISN лежит в пределах s_ack, s_ack+s_wind (s_wind - ширина окна для сервера; см. рис. .2.9). Аналогичный диапазон ISN для клиента выглядит как: c_ack, c_ack+c_wind (c_wind - ширина окна для клиента). c_wind и s_wind могут быть не равны. Пакеты, для которых эти условия не выполняются, будут отброшены.

Рассмотрим пример установления соединения для случая FTP-запроса (См. также http://www.cis.ohio-state.edu/~dolske/gradwork/cis694q).

Пусть клиент С запускает процесс установления FTP-соединения с сервером S. Обычный порядок установления соединения показан ниже (см. рис. 12):

c -> s:syn(isn_c)
s -> c:syn(isn_s), ack(isn_c)
c -> s: ack(isn_s) (Связь установлена)
c -> s: данные
и/или
s -> c: данные

ISN - идентификатор пакета, посылаемого клиентом (С) или сервером (S). Клиент, послав SYN серверу S, переходит в состояние syn_sent. При этом запускается таймер установления соединения. Как при установлении соединения так и при его разрыве приходится сталкиваться с проблемой двух армий. Представим себе, что имеется две армии А и Б, причем Б больше по численности чем А. Армия Б разделена на две части, размещенные по разные стороны от армии А. Если две части армии Б одновременно нападут на армию А, победа гарантирована. В то же время нападение на А одной из частей армии Б обрекает ее на поражение. Но как обеспечить одновременность? Здесь предполагается, что радио еще не изобретено и передача сообщений осуществляется вестовыми, которые в нашем случае могут быть перехвачены врагом. Как убедиться, что вестовой дошел? Первое, что приходит в голову, это послать другого вестового с подтверждением. Но он также с некоторой вероятностью может быть перехвачен. А отправитель не будет знать, дошел ли он. Ведь если сообщение перехвачено, отправитель первичного запроса не выдаст команды на начало, так как не уверен, дошло ли его первое сообщение. Возникает вопрос, существует ли алгоритм, который бы гарантировал надежность синхронизации решений путем обмена сообщениями при ненадежной доставке? Повысит ли достоверность увеличение числа обменов между партнерами? Ответом на этот вопрос будет - нет, не существует. В этом читатель, порассуждав логически, может убедиться самостоятельно. Не трудно видеть, что схожие проблемы возникают в любом протоколе, работающем через установление соединения. Чаще всего эта проблема решается путем таймаутов и повторных попыток (это, слава богу, не война и все обходится без людских жертв).

Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S (но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что имеет место случай одновременного открытия соединения. В результате он посылает syn_ack, отключает таймер установления соединения и переходит в состояние syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии не контролируется таймером, С может остаться в состоянии syn_received вечно. Из-за того, что переходы из состояния в состояние не всегда четко определены, протокол TCP допускает и другие виды атак (некоторые из них описаны в разделе “Сетевая безопасность”), там же рассмотрены алгоритмы задания и изменения ISN.

Хотя TCP-соединение является полнодуплексным, при рассмотрении процесса разрыва связи проще его рассматривать как два полудуплексных канала, каждый из которых ликвидируется независимо. Сначала инициатор разрыва посылает сегмент с флагом FIN, сообщая этим партнеру, что не намерен более что-либо передавать (FIN посылается, как правило в результате вызова приложением функции close). Когда получение этого сегмента будет подтверждено (ACK), данное направление передачи считается ликвидированным (реализуется полузакрытие соединения). При этом передача информации в противоположном направлении может беспрепятственно продолжаться. Когда партнер закончит посылку данных, он также пошлет сегмент с флагом FIN. По получении отклика ACK виртуальный канал считается окончательно ликвидированным. Таким образом, для установление связи требуется обмен тремя сегментами, а для разрыва - четырьмя. Но протокол допускает совмещение первого ACK и второго FIN в одном сегменте, сокращая полное число закрывающих сегментов с четырех до трех. Партнер, пославший флаг FIN первым, производит активное закрытие соедиения, а противоположный партнер (получивший FIN) отвечает на него своим FIN, осуществляя пассивное закрытие соединения. Инициатором посылки первого FIN может любая из сторон, но чаще это делается клиентом (например, путем ввода команды quit). Полузакрытие используется, например при реализации команды rsh (запуск операций в удаленном узле).

Машина состояний для протокола TCP (рис. 13) не предусматривает изменения состояний при посылке или получении обычных пакетов, содержащих данные.

Всего в машине конечных состояний протокола TCP имеется 11 состояний (CLOSED, LISTEN, SYN_RCVD, SYN_SENT и т.д., введены в RFC-793). Состояние CLOSED является начальной и конечной точкой диаграммы. ESTABLISHED указывает на то, что система находится в состоянии с установленным соединением. Четыре состояния в левом углу помещены в границы зеленой зоны и соответствуют активному закрытию. Состояния CLOSE_WAIT и LAST_ACK относятся к пассивному закрытию. Переход из состояния SYN_RCVD в LISTEN возможно, если переход в SYN_RCVD осуществлен из состояния LISTEN, а не из состояния SYN_SENT (одновременное открытие двух соединений, получение RST вместо финального ACK).

Рис. 13. Машина состояний для протокола tcp .

Состояние TIME_WAIT часто называется ожиданием длительностью 2MSL (Maximum Segment Lifetime). Значение MSL задается конкретной реализацией и определяет предельную величину пребывания сегмента в сети. В RFC-793 рекомендуется задавать MSL равным 2 мин. Но нужно помнить, что ТСР-сегмент транспортируется в IP-дейтаграмме, содержащем поле TTL. Когда модуль выполнил активное закрытие и в ответ на FIN послал ACK, соединение должно оставаться в состоянии TIME_WAIT в течение времени, в два раза превышающем MSL. Сокет, используемый данным соединение не может быть задействован другим соединением в продолжении указанного времени. Все сегменты данного соединения, задержавшиеся в пути, во время TIMR_WAITотбрасываются. Это гарантирует то, что сегменты старого соединения не будут восприняты новым соедиением. Такая процедура препятствует перезапуску серверов в течение 1-4 минут, так как в течение данного времени не могут использоваться стандартные значения номеров портов.

Состояние FIN_WAIT_2 сопряжено со случаем, когда одна сторона послала сегмент FIN, а другая сторона подтвердила его получение. Если данное соединение не нужно, можно ждать, когда приложение другой стороны получит код конца файла и пришлет свой флаг FIN. Только после этого система перейдет из состояний FIN_WAIT_2 в состояние TIME_WAIT. Теоретически такое ожидание может быть бесконечным. Другая сторона при этом остается в состоянии CLOSE_WAIT, пока приложение не вызовет функцию close. Для решения проблемы часто вводят дополнительный таймер.

В ТСР возможна ситуация, когда обе стороны запускают процедуру закрытия одновременно (посылают FIN), что в протоколе ТСР вполне допустимо. Каждая из сторон при этом переходит из состояния ESTABLISHED в состояние FIN_WAIT_1 (после вызова операции closed). По получении FIN стороны переходят из состояния FIN_WAIT_1 в состояние CLOSING и посылают ACK. После получения ACK происходит переход в состояние TIME_WAIT.

Когда оператор, работая в диалоговом режиме, нажимает командную клавишу, сегмент, в который помещается эта управляющая последовательность, помечается флагом PSH (push). Это говорит приемнику, что информация из этого сегмента должна быть передана прикладному процессу как можно скорее, не дожидаясь прихода еще какой-либо информации. Сходную функцию выполняет флаг URG. URG позволяет выделить целый массив данных, так как активизирует указатель последнего байта важной информации. Будет ли какая-либо реакция на эту "важную" информацию определяет прикладная программа получателя. urg-режим используется для прерываний при работе с FTP, telnet или rlogin. Если до завершения обработки "важной" информации придет еще один сегмент с флагом URG, значение старого указателя конца "важного" сообщения будет утеряно. Это обстоятельство должно учитываться прикладными процессами. Так telnet в командных последовательностях всегда помещает префиксный байт с кодом 255.

В режиме удаленного терминала (telnet/ssh) при нажатии любой клавиши формируется и поcылается 41-октетный сегмент, который содержит всего один байт полезной информации. В локальной сети здесь проблем не возникает, но в буферах маршрутизаторов в среде Интернет могут возникнуть заторы. Эффективность работы может быть улучшена с помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль предложил при однобайтовом обмене посылать первый байт, а последующие буферизовать до прихода подтверждения получения посланного. После этого посылаются все буферизованные октеты, а запись в буфер вводимых кодов возобновляется. Если оператор вводит символы быстро, а сеть работает медленно, этот алгоритм позволяет заметно понизить загрузку канала. Встречаются, впрочем, случаи, когда алгоритм Нагля желательно отключить, например, при работе в Интернет в режиме Х-терминала, где сигналы перемещения мышки должны пересылаться немедленно, чтобы не ввести в заблуждение пользователя относительно истинного положения маркера.

Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала.

Кларк предложил не посылать уведомление о ненулевом значении ширины окна при считывании одного байта, а лишь после освобождения достаточно большого пространства в буфере. Например, когда адресат готов принять MSS байтов или когда буфер наполовину пуст.

Предполагается, что получатель пакета практически всегда посылает отправителю пакет-отклик. Отправитель может послать очередной пакет, не дожидаясь получения подтверждения для предшествующего. Таким образом, может быть послано k пакетов, прежде чем будет получен отклик на первый пакет (протокол "скользящего окна").

В протоколе TCP "скользящее окно" используется для регулировки трафика и препятствия переполнения буферов. Идея скользящего окна отображена на рис. 14. Здесь предполагается, что ширина окна равна 7 (k=7; это число может меняться в очень широких пределах).

Рис. 14. Схема использования скользящего окна

После прихода отклика на пакет <1> окно смещается вправо на одну позицию. Теперь отправитель может послать и пакет <8>. Если порядок прихода откликов нарушается, сдвиг окна может задержаться. Размер окна в сегментах определяется соотношением:

window > RTT*B/MSS,

где B - полоса пропускания канала в бит/с, а MSS - максимальный размер сегмента в битах, а window - в сегментах.

Для протокола TCP механизм скользящего окна может работать на уровне октетов или сегментов. В первом случае нужно учитывать каждый раз размер поля данных переданного и подтвержденного сегмента.

Первый указатель определяет положение левого края окна, отделяя посланный сегмент, получивший подтверждение, от посланного сегмента, получение которого не подтверждено. Второй указатель отмечает правый край окна и указывает на сегмент, который может быть послан до получения очередного подтверждения. Третий указатель помечает границу внутри скользящего окна между уже посланными сегментами и теми, которые еще предстоит послать. Получатель организует аналогичные окна для обеспечения контроля потока данных. Если указатель 3 совпадет с указателем 2, отправитель должен прервать дальнейшее отправление пакетов до получения хотя бы одного подтверждения. Обычно получатель посылает одно подтверждение (ACK) на два полученных сегмента.

Контрольные вопросы:

1. Какие компьютеры называют серверами, а какие клиентами?

2. Каким образом построена архитектура взаимодействия программного обеспечения в системе WWW?

3. Назначение стека TCP/IP.

4. Объясните механизм формирования и передачи сообщений с использованием модели OSI.

5. Как функционирует протокол IP?

6. Объясните назначение полей в заголовке IP дейтаграммы.

7. Объясните процесс фрагментации.

8. Назовите основные характеристики ориентированных на соединение протоколов.

9. Как протокол TCP осуществляет передачу данных?

10. Что подразумевается под управлением потоком в TCP?

Методические указания к выполнению практических занятий (по дисциплинам «Интернет технологии», «Сети и системы документальной электросвязи»)

Рассмотрены на заседании кафедры СТ и рекомендованы к печати

(протокол № 4 от 25 сентября 2006 г.)

Составители:             Усманова Н.Б., Турсунходжаева Т.З. 

Редакционно-корректурная комиссия:

Ответственный редактор:                                 Камалов Ю.К.

                   Корректор:                                               Абдуллаева С.Х.